This invention relates to the field of maintaining data integrity. In particular, this invention relates to combining a commit command for a transaction with a subsequent operation instruction in an asynchronous messaging system.
Synchronization of transactions is required to maintain data integrity. For example, a sale transaction comprises the subtraction of money from a customer's account and its addition to the retailer's account. The two halves of the transaction must both occur in order to maintain the data integrity. If the subtraction from the customer's account takes place but an error occurs and the addition to the retailer's account does not take place the whole transaction must be backed out. Therefore, the transaction is only confirmed or committed once all parts of the transaction have been completed.
This concept has wide reaching applications across data systems. Data resources which require synchronization may be distributed with interconnection via network communications or may be local to a single computer system. A transaction coordinator can synchronize related changes to multiple data resources: either all related changes occur, or they are all undone.
In messaging systems, changes to a message queue resource are treated in the same way as changes to other data resources such as databases. This invention is described in terms of messaging systems; however, it can be applied to other systems with distributed resources which require transaction coordination.
In a messaging system, the decision to commit or back out the changes is taken, in the simplest case, at the end of a transaction. However, it can be more useful for an application to synchronize data changes at other logical points within a transaction. These logical points are called syncpoints (or synchronization points) and the period of processing a set of updates between two syncpoints is called a unit of work. Multiple messaging get and put operations can be part of a single unit of work.
When an application puts a message on a queue within a unit of work, that message is made visible to other applications only when the application commits the unit of work. To commit a unit of work, all updates must be successful to preserve data integrity. If the application detects an error and decides that the put operation should not be made permanent, it can back out the unit of work. When an application performs a back out, the system restores the queue by removing the messages that were put on the queue by that unit of work. The way in which the application performs the commit and back out operations depends on the environment in which the application is running.
Similarly, when an application gets a message from a queue within a unit of work, that message typically remains on the queue until the application commits the unit of work, but the message is marked as not available to be retrieved by other applications. The message is permanently deleted from the queue when the application commits the unit of work. If the application backs out the unit of work, the system restores the queue by making the messages available to be retrieved by other application.
Java Database Connectivity (JDBC a trade mark of Sun Microsystems, Inc.) includes an auto-commit mode in which an individual statement is treated as a transaction and is automatically committed after it is executed.
The prior art processes commit a set of operations after the last operation has been executed. An aim of the present invention is to provide an option when requesting an operation to commit any outstanding work prior to processing the operation.